Skip to content

perf(update): flush buffered in-place overwrites per storage page (C6, Fase B) - #379

Merged
MPCoreDeveloper merged 1 commit into
masterfrom
perf/batch-overwrite-flush
Sep 4, 2026
Merged

perf(update): flush buffered in-place overwrites per storage page (C6, Fase B)#379
MPCoreDeveloper merged 1 commit into
masterfrom
perf/batch-overwrite-flush

Conversation

@MPCoreDeveloper

Copy link
Copy Markdown
Owner

Samenvatting

Buffered in-place UPDATE-overwrites worden per storage-page geflusht (C6, eerste concrete Fase-B-mijlpaal).

De UPDATE-commit deed per rij 2 pwrites (lengte-prefix + payload): bij ~10K-rij UPDATEs domineerden de per-rij write-syscalls (~88K ops/s op de fair-PK fixed-width tabel, ~2,75x achter SQLite). Nu:

  • FlushBufferedOverwrites leest de on-disk content van elke geraakte storage-page één keer, patcht de rij-payloads in de kopie en schrijft elke page één keer.
  • Payloads die een page-grens kruisen gaan eerst via het directe per-record pad (zodat latere page-reads ze al bevatten); lengte-prefixes blijven onveranderd (same-length overwrites zijn het enige in-place geval).
  • Draait onder appendLock bij commit; rollback-semantiek ongewijzigd.

Metingen (fair-PK --pk, zelfde machine als master, 2 runs elk)

Variant master (#378) deze branch
fixed-width UPDATE 10K ~88K ops/s ~153-164K ops/s (+75-85%)
legacy UPDATE 10K ~53-56K ops/s ~64-70K ops/s (+20-25%)
fixed-width DELETE 10K ~109-131K ops/s ~119-130K ops/s (ruis)
legacy DELETE 10K ~74-76K ops/s ~76-84K ops/s (ruis)

UPDATE-gap vs SQLite op fixed-width: ~2,75x → ~1,7x.

Validatie

  • Nieuwe regressietest AscendingUpdateBatch_BatchedPageFlush_AppliesEveryRow_AcrossReopen: 2000-row UPDATE-batch (één commit, 2000 buffered overwrites → per-page RMW-flush), point reads + reopen.
  • Full suite: 1765 tests, 0 failed (Release).

…, Fase B)

The UPDATE commit path buffered one record per row (B7) and FlushBuffered-
Overwrites wrote each with two pwrites (length prefix + payload). ~10K-row
UPDATEs were therefore dominated by per-row write syscalls (~88K ops/s on the
fair-PK fixed-width table, ~2,75x behind SQLite). The flush now reads the
current on-disk content of each touched storage page once, patches the row
payloads into the copy, and writes the page once. Payloads that cross a page
boundary take the direct per-record path first so later page reads already
include them; length prefixes are unchanged (same-length overwrites are the
only in-place case). Runs under appendLock at commit; rollback semantics
unchanged (buffers still dropped on rollback).

Fair-PK harness (--pk, same machine as master, 2 runs each):
  fixed-width UPDATE ~88K -> ~153-164K ops/s (+75-85%; gap vs SQLite ~1,7x)
  legacy UPDATE      ~53-56K -> ~64-70K ops/s (+20-25%)
  DELETE within noise.

Regression: AscendingUpdateBatch_BatchedPageFlush_AppliesEveryRow_AcrossReopen
(2000-row UPDATE batch = one commit with 2000 buffered overwrites; point reads
+ reopen verify the page read-modify-write flush). Full suite 1765 tests, 0 failed.
@sonarqubecloud

sonarqubecloud Bot commented Sep 4, 2026

Copy link
Copy Markdown

@MPCoreDeveloper
MPCoreDeveloper merged commit 30acd8b into master Sep 4, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant